IBIS Macromodel Task Group Meeting date: 21 Jun 2011 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Ansoft: Chris Herrick Danil Kirsanov Ansys: Samuel Mertens * Dan Dvorscak Deepak Ramaswamy Jianhua Gu * Curtis Clark Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Celsionix: Kellee Crisafulli Cisco Systems: * Mike LaBonte Stephen Scearce Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Mentor Graphics: * John Angulo Vladimir Dmitriev-Zdorov Zhen Mu * Arpad Muranyi Micron Technology: Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski Sigrity: Brad Brim * Kumar Keshavan Ken Willis SiSoft: * Walter Katz Mike Steinberger Todd Westerhoff Doug Burns Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad submit AMI_parameter BIRD to open forum - Done - Arpad submit Bob's BIRD to open forum - Done - Arpad add abbreviation periods to Corner Range BIRD draft - Done ------------- New Discussion: Arpad showed the Format Corner and Range Clarification BIRD: - Arpad: Are there any comments? - Fangyi: Please clarify the 2nd paragraph on page 2 - Arpad: It instructs tools to use AMI corners - We may make changes later - Radek: It would be better not to specify anything - It can be left to the EDA platform or the user - Ambrish: There is more to this than it says - Arpad: Then it would be ambiguous what typ, slow and fast mean - Radek: The first 3 lines should be kept - The rest of the paragraph can go - Mike: The last sentence can be kept - Walter: The one before that can be kept too - Arpad highlighted the middle sentences proposed for deletion - John motioned to submit this with selected text removed - Bob seconded - The motion passed by acclamation Arpad showed the task list: - Arpad: This was updated an hour before the meeting - Everyone should check especially the cyan colored ones - Arpad reviewed some of the tasks - Item 35: - Arpad: Should item 35 should in 5.1 or be pushed out? - Walter: We will be more clear on this when when handle analog models - Ambrish: Not sure how analog relates - Arpad: There was talk about using Thevenin equivalents to generate impulse response - Walter: The analog BIRD will satisfy people who want that - Kumar: It could be a silicon model generating the impulse response - Ambrish: AMI is supposed to be conjoined with IBIS - Arpad: The spec currently says nothing about this - The question now is if this should be in 5.1 - Todd: A model without analog is non-compliant - Arpad: Should that be said in the spec now? - Ambrish: It says that now - Page 139 - At most, an impulse response example might help - Arpad: We will need graphics for that - Ambrish: It could be ASCII - Todd: The only fuzzy part of that is what the magnitude should be - This is more of a cookbook item - Arpad: We can consider this to be tabled Items 46 & 47: - Walter: Some models use those - They have to stay - Arpad: These will be marked "do nothing" Item 56: - Radek: Initialization is a good practice - Arpad: I may not make sense to have it for Usage Out - Bob: It is easier to leave it - Fangyi: It doesn't hurt to have a default - Arpad: We can put this off Item 63: - Walter: The AMI_Close function call is required - Arpad: Disagree - Dan: Close is required only if GetWave exists - Arpad showed the IBIS 5.0 spec page 181 "Case 3: Shared library has only AMI_Init" - Walter: That should be deleted - Todd: Agree - Arpad: Should this be in 5.1? - Bob: We should have a BIRD - Todd: It should be solved soon - Fangyi: It says elsewhere that AMI_Init is required Walter showed his New Reserved Parameters for Data Management BIRD draft: - Adds Supporting_Files, DLLPath, and DLLid - Walter: Some models require supporting files - The EDA tool knows where the DLL file is, the DLL doesn't - Ambrish: Is this Model_Specific? - Walter: It is now - It needs to become reserved for wide usage - Fangyi: This is a relative path? - Walter: It could be absolute or relative to CWD - Radek: This is not portable - Walter: The Value is shown as NA - The tool will fill it in - Fangyi: So it is not in the AMI file - Walter: It is in the AMI file - The EDA tool replaces the value - Fangyi: How does the tool know where the other files are? - Walter: Files should be in the same directory as the IBIS file - Radek: How do relative paths work? - Walter: The DLL calls open() with whatever path it gets - Kumar: Some vendors may not put them in the same directory - Walter: IBIS requires it - Ambrish: Agree - Walter: DLLid is for multiple instances of the same DLL - The can be file writing collisions - This provides an ID to create unique names to avoid overwriting - Kumar: For temporary files it has to use the ID? - Walter: DLLs need to make sure they don't collide somehow - Kumar: The tool could put the DLLs in different directories - Radek: In what situation would this be needed? - Walter: Where two models use the same DLL - The last parameter is Supporting_Files - This tells the tool to always move these files together - This can be used to support multiple versions of Matlab, for example - Fangyi: Developers might be confused about what to use for DLLPath and DLLid. - Arpad: How to give a different path for each DLL? - It doesn't say the path is relative - Walter: Supporting files are relative to .ibs directory - Arpad: Different OSes may be a problem - Fangyi: Does DLLPath apply to supporting files? - Radek: What is the Usage type for this? - Walter: Info - Developers should check on all of this Meeting ended. ------------- Next meeting: 5 July 2011 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives